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0 Local area network for digital data processing system. 



@ A local area network for Interconnecting tenni- 
nais and otiier users and data processing systems 
and other service providers over a communications 
link. The users and providers connect to the commu- 
nications link by means of interface units each of 
which may connect to several users or providers. 

2f The interface units communicate over ttte commu- 
nications link by means of messages. When a user 

^requires the use of a service, ttie interface unit 



establishes a virtual circuit between it and the inter- 



(O 
(O 

fac^ unit connected to tiie service provider and a 
JJ'senrice session which allows the user and the ser- 
Pjvice provider to communicate over tiie virtual circuit. 

[f several users connected to the one interface unit 
® as the first user require services provided by provid- 
(Lers which connected to ttie same interface unit as 
lUthe first provider, tfney communicate in sessions over 

tiie same virtual circuits. The session messages are 

accumulated into single virtual circuit messages that 



are acknowledged in unison by the receiving inter- 
face unit Each virtual circuit in the users' interface 
units includes a timer which reset when a message 
is transmitted over the virtual circuit and a data 
waiting flag set whenever data is present to be 
transitted over ttie virtual circuit The interface units 
are inhibited from transmitting over a virtual circuit 
unless the timer has timed out and tiie data waiting 
flag is set 
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Background of the Invention 



1 . Reld of the Invention 

The invention relates generally to the field of 
digital data processing systems and more specifi- 
cally to local area networks in which a plurality of 
such systems are interconnected to provide distrib- 
uted processing capabilities to a numt>er of users. 
In particular the invention provides improvements 
in message transfer protocols for local area net- 
works to enhance the message transfer capability 
of the network. 



2. Description of the Prior Art 

As small and medium-sized computer systems 
are becoming less expensive and more powerful, a 
numt)er of them are being interconnected to form 
networks to ensure that a number of different types 
of services are available at any time to users 
havirtg diverse processing needs. Such services 
may include any of the services which are nonnaily 
available from such networks, including such as 
electronic mail (mail storage and forwarding), word 
processing, accounting, such as payroll or inven- 
tory, or data communications over tel^>hone lines 
or microwave finks. Interconnecting systems into a 
network helps to enhance the availability of ser- 
vices to service users by including a number of 
service providers in the network and having each 
provider provide one or more of the services, thus 
reducing the likelihood that the failure of any one 
service provider in the network will result in a 
significant number of servrces being unavailable to 
the users at any one time. Indeed, a local network 
may be arranged so as to have several service 
providers providing overlappirig services, in which 
case several providers have the atMlity to provide a 
particular service if one service provider falls or is 
saturated with service requests. 

Typically in a local area network, the cornmu- 
nicatlons in the network take place over one or a 
limited number of communications finks. Examples 
of such communications links include those defined 
by well-known DECnet SNA (System Network Ar- 
chitecture) or X25 communications protocols using 
data links such as Bhemet A number of service 
users, such as. for example, video terminals con- 
trolled by operators, are connected through inter- 
face devices known as "terminal servers" to the 
communications links. Similarly, the service provid- 
ers aire connected to the communications link 
through interface devices known as "nodes". 

If the operator desires to use a service pro- 
vided by a unit connected to a node, it may re- 



quest connection to the node and, through the 
node, to the unit to have the service provided. 
Normally, the operator has to know the particular 
node{s) and unit{s) that provides the desired ser- 

5 vice. The operator selects a node and unit to 
provide the service, and causes the terminal server 
to request service by that node and service pro- 
vider. The terminal server and the node exchange 
messages which enable a "virtual circuit" to be 

70 established which provides a data transfer mecha- 
nism between the operator's tenninal and the pro- 
vider of the service. The virtual circuit essentially 
extends from the operator's terminal, as the sendee 
user, through the terminal server, over the commu- 

/5 nications link and through the node to the service 
provider. If a number of users are using the local 
area network, several virtual circuits may be estab- 
lished over the communications link to provide 
communications between the users and providers. 

20 In addition, if several terminals connected to one 
terminal server require services from a service 
provider connected to the same node, separate 
virtual circuits are normally established between 
each terminal and service provider providing the 

25 required service. 

Service data is transmitted in the form of mes- 
sages through the virtual circuits t3etween the ter- 
minals and the service providers. All of the mes- 
sages are queued by the terminal server and trans- 

30 mitted over the single communications link. To 
ensure that the messages are received, units con- 
nected in the network re-transmit the message until 
an acknowledgement from the recipient is received 
verifying correct receipt. Specifically, the terminal 

35 servers and nodes, after they transmit messages 
through the virtual circuits over the communications 
links, monitor the communk:ations link for acknowl- 
edgements and if rK> acknowledgement is received 
within a selected period of time, corrective action Is 

40 taken. Each message transmitted through a virtual 
circuit is acknowledged by a separate acknowl- 
edgement message through the virtual circuit, even 
^ if a-^ries of messages are transmitted between 
the same terminal server and node through dif- 

45 ferent virtual circuits over the same communica- 
tions link. Each acknowledgement message must 
separately generated, and thus requires that 
time and facilities be dedicated at the receiving 
device to the generation of the separate acknowl- 

50 edgement messages. Furthermore, requiring such 
separate ackrtowledgement messages could cause 
the communications link to quickly become unnec- 
essarily burdened. 

In current networks, message transfers through 
virtual circuits over a communications Gnk are ini- 
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tiated either by the occurrence of certain events 
{."event driven" transmission), such as the pres- 
ence of data to be transmitted, or by the timing-out 
of certain timers {"timer-t)ased" transmission). Both 
the event-driven and timer based message transfer 
systems incorporate certain assumptions about 
message traffic through virtual drcuits over the 
communication link. The event driven systems as- 
sume that the communications link has sufficient 
bandwidth, even when it is being heavily used, to 
ensure that messages can be delivered from the 
terminal servers to the nodes, the messages can 
be processed by the sen/ice providers, and the 
responses to the messages can be returned to the 
terminal sewers, all within a maximum tolerable 
delay period. If the communications link carries too 
high a level of message traffic, the delays will, 
however, become unacceptably long. Furthermore, 
if a unit transmits data every time it receives a few 
bytes of data from a service user or provider, a 
significant number of such messages will be com- 
posed primarily of virtual circuit identification in- 
formation, which is necessary to ensure proper 
identification of the virtual circuit carrying message 
over the multiplexed communications link but oth- 
erwise serves no purpose. 

Timer-based message transmission systems 
ensure, on the other hand, that every unit con- 
nected to the communications link will be able to 
transmit messages over the link at periodic inter- 
vals. These systems ensure that all of the units 
have relatively uniform access to the communica- 
tions link. However, such systems also have a 
number of deficiencies. Rrst. each unit when its 
time comes to transmit transmits messages 
through its virtual circuits whether or not it has any 
data to transmit obviously wasting bandwidth on 
the communications link. Furthermore, as units are 
added to the system, the timers of all of the units 
would have to be adjusted to ensure that all of the 
units have reasonably equal access to the commu* 
nications link. 



Summary of the Invention 

The invention provides a new local area net- 
work message transfer system which has enhanced 
message throughput t)6tween service users and 
service providers over a communications link in a 
local area network, while at the same time ensuring 
that all units have a relatively uniform access to the 
communications link for transfenring messages. 

In brief summary, the invention provides a local 
area networit over which a plurality of users, such 
as terminals or printers, communicate with service 
providers, such as data processing systems, data 
storage devices such as disk or tape records, or 



data links such as telephone lines or microwave 
transmission links. One or more device servers 
connects directly to a communications link. Each 
device server is an interface to the communications 

5 link for one or more of the users. Similarly, one or 
more nodes connects to the communications Unk, 
and each node Is an interface to the communica- 
tions link for one or more service providers. Pe- 
riodically, each node transmits a service advertis- 

10 ing message over the communication link which 
includes its identification, the identifications of the 
services that are provided by the sennce providers 
connected to it and a ratings for each of the 
services. Each device server receives these mes- 

75 sages and records them in a service directory. The 
services available to a user by the service provid- 
ers in the networi< rinay be viewed by the operators 
from the service directory stored by the device 
servers. 

20 When an operator desires to use a service in 
the service directory, it enables the device server 
to request tfie service. The device server then 
selects the particular provider to provide the ser- 
vice based on the ratings in the service directory, 

25 and identifies the node tiirough which communica- 
tions with the service provider can be conducted. If 
ttie device server is not then communicating with 
ttiat node, it and Oie node establish a virtual circuit 
ttirough which they transfer messages. In addition. 

30 tfie device server estabBshes a service session 
between Itself the user whose operator Is request- 
ing the service, and the node establishes a service 
session between itself and the service provider 
connected to that node v^ich provides tiie service 

. 35 requested by ttie user, witii the service sessior>s at 
tfie device server and node, respectively, being 
linked and tiie identification of tt^ session being 
known to the unit ttiat is. the device server or 
node, at tiie other end of the virtual circuit If any 

40 oiher users request services provided by service 
providers connected to that same node, similar 
sessions are established for those users by the 
device server and for the service provider by ttie 
nodes, and messages for all such sessions may be 

45 transfenred through the same virtual circuit mul- 
tiplexed In slots in ttie same virtual circuit message 
which serves all of the service users or providers. 
Therefore, the device server need not establish a 
new virtual circuit for every devrce which requires 

50 the service provided by a service provider con- 
nected to that node. Furtttermore. only tfie virtual 
circuit messages are acknowledged, rather than the 
individual messages between service users and 
providers, thereby reducing tiie number of ac- 

65 knowledgement messages transfen'ed and ttie re- 
sources at the device senrers and nodes required 
to generate the acknowledgement messages. 

Generally, message transfers between a device 
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server and a ncxle through a virtual circuit are 
initiated by a device server, and each message 
from a device server to a node is acknowledged by 
a message from the node. Each message includes 
a response requested flag which may be set or 
cleared by the node. The response requested flag 
is set if the message includes session slot data, 
otherwise the flag is cleared. The portion of each 
virtual circuit In the device server Includes a server 
circuit timer and a data waiting flag (DWF) which is 
set either by the receipt of a message from the 
node having a set response requested flag or in 
response to the receipt of slot data from the ser- 
vice users which use the virtual circuit Nonmaily. 
the node will send a message only in response to a 
message from tfie device server; however, if the 
response requested flag in the prior message was 
cleared, which occurs if the node did not send any 
data in the prior message, the node may send 
another message to the device server which in- 
cludes data t^efore it receives a subsequent mes* 
sage from the device sender. When a device server 
transmits a message through tine virtual circuit over 
the communications link, the server circuit timer, 
pre-set to a selected value, begins to decrement 
When tfie server circuit timer times out and iftiie 
data waiting flag is set. the device server transmits 
a message tiirough ttie virtual circuit Until the 
server circuit timer times out, tiie device server is 
inhibited from transmitting a new message over tiie 
virtual drcuit Furthermore, the data waiting flag 
inhibits tiie device server from transmiting any 
messages until \he data.,waiting. flag is set indicat- 
ing it has received a message from the node in 
which the response requested flag is set or that Is 
has new slot data from the service users to send. 

The response requested flag allows the node 
to immediately acknowledge a message received 
from ttie device server, whether or not it has data 
to send immediately, and to reserve for itseff the 
ability to transmit a second message which has 
data if no data is sent in tiie initial message, which 
second message can be s^t even if it receives no 
inten/ening message from the device server. The 
response requested flag in conjunction with the 
data waiting flag allows the node to force the 
device server to acknowledge a message that in- 
cludes data when tire server circuit timer next 
times out, whether or not the device server has 
data to send. The server circuit timer establishes a 
minimum delay period after the device server 
transmits a message before it transmits a sut)se- 
quent message, tiiereby allowing other device serv- 
ers to transmit messages through virtual circuits 
which tiiey have established over the communica- 
tions link. The device server and the node thus 
have tiie benefit of botti a timer based system, 
based on the server circuit timer, and an event 



driven system, based on the response requested 
and data waiting flags. 



5 Brief Description of the Drawings 

This invention is pointed out with particularity 
in the appended claims. The above and further 
advantages of ttiis invention may be better under- 

10 stood by referring to ttie following detailed descrip- 
tion taken in conjunction witii the accompanying 
drawings in which: 

FIG. 1 is a general block diagram of a local 
area network constructed in accordance with this 

75 invention; 

FIG. 2A is a diagram illustrating tiie contents 
of a service advertising message transmitted by 
ttie service providers in Uie network depicted in 
RG. 1, and FIG. 2B is a diagram of a data base 

20 established by the service users in the network of 
RG. 1 in response to the service advertising mes- 
sage depicted in FIG. 2A; 

FIG. 3A is a diagram depicting a virtual 
circuit and service sessions tiiat is useful in under- 

25 standing the operations of the network depicted in 
FIG. 1; 

RGS. 38 and 30 are diagrams depicting 
databases used by tiie service providers and ser- 
vice users in the network depicted in RG. 1; 
30 RG. 4 Is a state diagram useful in under- 

standing tiie operation of the virtual circuit depicted 
in FIG. 3A; 

FIG. 5 is a state diagram useful in. under- 
standing the operation of the service sessions de- 
35 picted in FIG. 1; 

RGS. 6A tiirough 60 depict the formats of 
virtual circuit messages transmitted through the 
virtual circuit depicted in RG. 3A; 

RGS, 7A tiirough 70 depict ttie fomiats of 
40 session skvt messages transmitted between cor- 
responding sessions in the device servers and 
nodes as depicted in RG. 3A; and 

RG. 8 depict ttie timings of messages trans- 
mitted tiirough the virtual circuits as depicted in 
45 RG. 3A. 



Detailed Description of an Illustrative Emtwxtlment 

50 RG. 1 illustrates a local area network 10 in 
which a plurality of service users, generally in- 
dicated by reference numeral 12, communicate 
with a plurality of service providers, generally in- 
dicated by reference numeral 14, over a common 

55 communications link 16. A communications link 16 
may take ttie form of any one of a numt)er of 
communications lines and interface circuitry which 
transfer data between the service users and service 
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providers in bit serial or parallel form. For example, 
the communications link may take the form of a 
coaxial cable and interface circuitry which transmits 
messages using the well-known Ethernet local area 
network protocol. In that protocol, data is organized 
into messages having a predetermined format and 
transmitted in bit serial form between stations over 
the coaxial cable. A number of other communica- 
tions links using diverse protocols exist which 
coukJ also be used in the local area network de- 
picted in FIG. 1; the specific communications link 
selected is not an aspect of the invention. 

The service users 12 may include a plurality of 
devices such as. for example, video display termi- 
nals 18. printers 20, and personal computers 22. 
Network 10 also includes a plurality of device serv- 
ers 24 each of which connect to several service 
users and enable the service users to communicate 
over communications link 16 with the service pro- 
viders 14. The service providers 14 may include 
devices such as processors 26. disk drives 28. 
tape storage units 30 and data links 32 (such as 
telephone lines or microwave links) and analog-to- 
digilal converters 33. Network 10 also includes a 
plurality of nodes 34, each of which may be con- 
nected to several service providers. Furthermore, 
each node 34 connects directly to communications 
link 16 and provides communications t)etween the 
service providers connected to it and the commu- 
nications link. It will be appreciated that in some 
cases a service provider and node may be in- 
tegrated into one unit that performs both functions. 

The service providers 14 provides service to 
the service users 12. Such services may include, 
for example, electronic mail storage and forwarding 
among service users, word processing capabilities, 
access to programs such as payroll accounting, 
inventory control or the like, the ability to store or 
retrieve records on or from disk and tape files, the 
alwlity to communicate over telephone lines and 
microwave links, and the ability to acquire data 
from, for example, sciwtific instruments through 
analog-tCKJigital converters 33. Such services, as 
well as additional servk:es, are well known in the 
art and will not be discussed further herein. 

It will be appreciated by those skilled in the art 
that some service users may also provide sendees. 
For example, certain personal computers 22 in 
ne^ric 10, in addition to being a service user, 
may also have programs that may be accessed 
and used by another user, such as a terminal 18. In 
that case, the personal computer may be con- 
nected to a node 34 as well as to a device server 
24 to make its programs available to a servrce user 
as services. A unit which interfaces the personal 
computer to the communications link may provide 
the facilities of both a node and a device server. 

Periodically, each node 34 transmrte an 



"advertising" message which is received by all of 
the device servers 24. which identifies itself and 
tiie services provided by the service providers 14 
connected to that node, as well as a "rating" for 

5 each service. VyTith reference to FIG. 2A, the ser- 
vice advertising message includes a plurality of 
fields including a header 50 which depends on tiie 
protocol used over a communications line 16 and a 
body 54. in one embodiment, the header 50 has a 

10 node identification field 51 which identifies the 
transmitting node, a protocol type field 52 identify- 
ing the message as the service advertising mes- 
sage, and a multi-cast address field 53 which er>- 
ables all of the device servers 24 to receive the 

IS message. Following the header 50, the node trans- 
mits the body 54 of the message which identifies 
the various services provided by it and the rating 
for each service. The ratings indicate, for example, 
how prompt tiie service provider 14 may be in 

20 responding to a service request, based in part on 
the number of service users 12 ttien using tine 
sendee provided by tiie specific provider and, thus, 
tiie potential delay in responding to communica- 
tions from another service user who might request 

25 the service. 

After receiving service advertising messages 
from ttie nodes 34, each device server 24 (FIG, 1) 
establishes a service directory such as depicted in 
RQ. 2B. The directory comprises a table in v*fhich 

30 the node identifications, tiie services provided by 
ttie nodes, and the service ratings are stored. Thus, 
if an operator at a service user 12 desires to use 
one of tiie services shown in the directory, the 
device server can use the contents of the service 

35 directory depicted in RG. 2B to detennine which 
nodes provide that service. If more than one node 
provides the service requested, the device server 
uses the rating in the rating fields to determine 
which node has the highest rating for tiie service 

40 and requests that node to provide tiie service. 

The diverse services that are available from the 
service providers may be divided into groups or 
classes and each user may be a!bie to access only 
those sen/ices ttiat are of interest to him. The 

45 service names may be organized into groups iden- 
tified by group nannes. and the device server will 
display only tiiose services to a particular user 
which are in the groups which ttie user can access, 
\/Vhen a user 12 requires a senrice provided by 

50 a servw:e provider 14 identified in tiie service direc- 
tory, the device server 24 begins to establish a 
virtual circuit 58 between itself and tiie node 34 
that provides the service with the most desirable 
senrfce rating, Witti reference to RG, 3A, ttie de- 

55 vice server 24 in a conventional manner estab- 
lishes a virtual circuit state machine 60 which pro- 
vides two-way data communications over a pair of 
unidirectional data pipes with a virtual drcuit state 
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machine 64 established by node 34. The virtual 
circuit state machines 60 and 64 and the data 
pipes 62 provide a means for transfenring data, in 
the form of messages between the device server 
24 and the node 34 over the communications link 
16. It will be appreciated that message communica- 
tions through a numt^er of data pipes 62 may be 
multiplexed over the communications link 16. and. 
accordingly, the communications link provides 
message communcations for a number of virtual 
circuits in network 10. 

The virtual circuit state machine 60 at the de- 
vice server 24 communicates with the individual 
service users 12 by means of service sessions 
using separ^ session state machines 68 which 
the device server establishes in a conventional 
manner lor each user. Similarly, the node's virtual 
state machine 64 communicates with the service 
providers 14 using separate session state ma- 
chines 68. 

The device server 24 and node 34 use mes- 
sages transmitted over communication link 16 to 
set up the virtual circuit and tfie session state 
machines, which will be described below in con- 
nection with RGS. 4 through 7D. In brief, however, 
when a user 12 requires service by a service 
provider 14. the device server 24 first determines 
wtiether a virtual circuit exists between it and the 
node 34 selected by the device server. If no such 
virtual drcuit exists, the device server 24 transmits 
a virtual circuit message over communications link 
16 to node 34 which causes tiie node to establish 
its virtual circuit state machine 64 to support its 
end of the virtual drcuit 58. A session state mar 
chine 66 is also set up between its virtual drcuit 
state machine 60 and the user 12 to allow data and 
other infomnation to be accumulated from and 
transferred to the user. 

In a ^cceeding virtual circuit messages, after 
the virtual drcuit is set up. a session slot is trans- 
mitted by device server 24 to node 34 through the 
virtual drcuit 58. specifically over the communica* 
tions nnk 16. identifying the required service, and 
the node 34 sets up a session state machine 68, 
which connects to the service provider which pro- 
vides the required service and allows data and 
other information to be transfenred between tiie 
virtual drcuit state machine and the service pro- 
vider. Each session state machine collects informa- 
tion to be transferred from its connected user or 
service provider and provides the information in the 
form of session messages to the virtual drcuit state 
machine, which in tum accumulates tiie session 
messages from various service users' or providers' 
state machines which are to be transfeaed be- 
tween tiie same device server 24 and node 34 and 
fonms a single virtual drcuit message for transfer 
through the virtual drcuit 58 over ttie communica- 



tions link 16. On receiving a virtual drcuit message 
from the virtual drcuit 58, tiie receiving virtual 
drcuit state machine transfers the session mes- 
sages to the respective session state machines that 

5 are ttie intended recipients for transfer to the re- 
spective service users 12 and service providers 14. 
and returns a single acknowledgement message 
over the virtual drcuit to verify receipt of the virtual 
circuit message. It will t>e appreciated that requir- 

70 ing only a single virtual drcuit acknowledgement 
message for tiie multiplexed messages between 
service users and providers reduces tiie acknowl- 
edgement message tratftic from that often required 
in tiie prior art. tiiereby reducing the traffic over- 

/5 head over communications link 16. and also re- 
duces the overhead required at tiie device server 
and node to generate tiie acknowledgement mes- 
sages. 

The virtual state machines 60 and 64 in device 

20 server 24 and node 34 respectively include a data 
base as depicted in R6. 3B used in transmitting 
and receiving messages through pipes 62. Data 
base 70 includes a remote identification word 72 
and a local identification word 74. The identification 

25 words 72 and 74 contain tiie identification of tiie 
virtual drcuit 58 as assigned by node 34 and 
device server 24. The contents of tiie local iden- 
tification word 74 are assigned by tiie unit in which 
the data base 70 resides, and the contents of the 

30 remote identification word 72 are assigned by the 
other unit engaged in tiie virtual drcuit Thus, in the 
virtual drcuit data base 70 which resides in device 
server 24. the local identification word is assigried ' 
by tiie device server and tiie remote identification 

35 word is assigned by the node 34 whteh provides 
tiie other end of tiie virtual drcuit Similarly, in the 
virtual drcuit data base 70(RG. 3B) residing in 
node 34, tiie contents of the local identification 
word 74 are assigned by the node, and tiie con- 

40 tents of tiie remote identification word 72 Is as- 
^gned by the device server. The contents of the 
two identification words 72 and 74 are transmitted 
in the virtual drcuit messages transfenred tiirough 
the virtual drcuit over communications link to allow 

46 the device server and node to identify the mes- 
sages transfenred over communications link 16 as 
being associated witti tiie particular virtual drcuit 

The virtual drcuit data base 70 also includes a 
message type field 76 which identifies the type of 

50 virtual drcuit message to be transmitted next 
Three types of virtual drcuit messages are trans- 
mitted over a virtual drcuit namely, a START 
virtual drcuit message, a RUN message, and a 
STOP virtual circuit message, which are detailed 

55 below in connection witii FIGS. 4 and 6A tiirough 
6D. 

An M field 78 identifies whetiier the unit includ- 
ing tiie data base 70 is a master or slave unit In 
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the network 10 (FIG. 1) device servers 24 are 
always masters and nodes 34 are always slaves; 
communications over a virtual circuit are always 
initiated by the device servers and the nodes al- 
ways acknowledges or responds to the commu- 
nications from the device servers. 

An R field 80. when set indicates that the last 
sent message requires a response. 

Data base 70 also includes message counters 
82 and acknowledgement counters 84. Each mes- 
sage transmitted by device server 24 or node 34 
includes a message sequence number that is 
checked by the virtual circuit state machine In the 
receiving unit to ensure that the successive mes- 
sages are properly received in sequence. Mes- 
sages are re-transmitted to ensure that they are 
properly received if they are not acknowledged 
within a predetermined time; the sequence num- 
bers ensure that the receiving device does not treat 
a re-transmitted message as a new message i^ it 
in fact, correctly received the message on a pre- 
vious transmission. The contents of the message 
counters 82 identify the number of messages 
which have been transmitted and received, and the 
acknowledgement counters contain the message 
numfciers of the messages which have been ac- 
knowledged. Thus, if a message number is skip- 
ped, or if acknowledgements are not received in 
numerical order, the device server and node can 
detenmina which messages may have not Ijeen 
properly transmitted over communications link 16. 

A data waiting flag (DWF) 86 is set whenever 
any session state machine has data to send over 
the virtual circuit In a device server 24, the data 
waiting flag is set when a message is received 
from a rwde which requires a response. 

A retransmit counter 88 and retransmit timer 90 
are used in retransmitting messages which have 
not been acknowledged within a time selected by 
the retransmit timer. The transmitting unit retrans- 
mits each unacknowledged message a number of 
times as selected by the retransmit counter 88. If 
the message is not acknowledged after the retrans- 
mit counter counts out the other end of the virtual 
circuit Is marked out of service. 

The virtual circuit data base 70 in a device 
server 24 also Includes a server circuit timer 92. 
When the device server 24 transmits a message, it 
resets its server circuit timer 92 and is thereafter 
inhibited from transmittting a subsequent message 
until the server circuit timer times out Thus, even if 
the data waiting flag 86 is set indicating that the 
device server has information to transmit in a vir- 
tual circuit message, the device server is inhibited 
from transmitting virtual circuit messages over vir- 
tual circuit 58 until the server circuit timer times 
out. Conversely, even if the server circuit timer 92 
has timed out the device server 24 does not trans- 



mit any messages unless the data waiting flag 86 
is set After the server circuit timer times out if the 
virtual circuit's data waiting flag 86 is thereafter set 
and the previously transmitted messages have 

5 been acknowledged, the device server 24 may 
then immediately transmit a new virtual circuit mes- 
sage over the virtual circuit 58. If a previously 
transmitted message has not been acknowledged, 
a device server or node waits an amount of time as 

10 specified by the retransmit timer 90 and then re- 
transmits the unacknowledged message. 

The server circuit timer 92 thus ensures at 
least a minimum delay period between the trans- 
mission of new virtual circuit messages by the 

75 device server 24 through any particular virtual cir- 
cuit Thus, when traffic is heavy through the virtual 
circuit and the data waiting flag is set t>efore the 
server circuit timer times out. message transmis- 
sions will be based on the timing out of the server 

20 circuit timer 92. However, if traffic is light through 
the virtual circuit, the virtual circuit message trans- 
mission will be based on the setting of the data 
waiting flag 86. Since, with one exception as ex- 
plained below, the nodes 34 only respond to or 

25 othenwise acknowledge virtual circuit messages 
from the device servers, the server circuit timers 
and the data waiting flags in the device servers 
also govern message traffic from the nodes 
ttirough tiie virtual circuits. The network 10 (RG, 1) 

30 thus achieves the benefits of both the timer-based 
message transfers and the event-driven message 
transfers, the event-driven transfers t)eing initiated 
by tiie presence of infonmation from user 12 for 
transfer over the virtual circuits, and the timer- 

35 based message transfers being based on the tim- 
ing out of tiie server circuit timer, without having 
ttie detiiments of either. 

The virtual drcuit data base 70 in a device 
server 24 also Includes a keep-alive timer 94 which 

40 enables the device server to send a message over 
the virtual drcuit if it has not sent any messages 
tiiereover for a very long period of trntie, to ensure 
tiiat tile node 34 maintains support for its end of 
the virtual drcuit. The node 34 responds thereby 

45 infonnning ttie device server ttiat it has not gone 
down. 

As noted above, the service user arwj service 
provider providing ttie servk» required by ttie user 
communicate by means of session stots. More 

50 spedficaily. the session state machines at tiie de- 
vice server and node transfer session slots which 
cause transitions between states in the respective 
session state macfrines and also transfer service 
data and status information between the service 

55 user and provider. 

Each session state machine uses a session 
data base 100 depicted in RQ. 3C. The session 
data base includes a remote identification field 102 



7 



13 



EP 0 375 664 A2 



14 



and a local identification field 104, which are used 
in the same way as a virtual circuit state machine 
uses the remote and local identification fields 72 
and 74 in the virtual circuit data base 70(FIG. 3B). 
Specifically, each virtual circuit message that is 
transmitted over a virtual drcuit may include ses- 
sion slots for different service sessions (that is. 
session slots intended to t»e used by different 
session state machines In the device servers and 
nodes that communicate over the same virtual dr- 
cuit) and the remote and local identiftcation fields 
102 and 104 identify the session and session state 
machines that are the Intended redpients of the 
session slots. The contents of local identification 
field are assigned by the unit in which the data 
t>ase resides, and the contents of the remote data 
base are assigned by the other unit. 

Each session data base 100 also includes a 
data buffer 106 for storing data received from or to 
be transmitted to the service user 12 or service 
providers 14 assodated with the particular session 
state machine. 

When the data buffer 106 is loaded with data 
from the user 12 or service provider 14 connected 
to the particular session state machine, a data 
ready flag 108 is set which in turn enables the 
data waiting flag 86 in the virtual drcuit data t^ase 
70 to be set When the device server or node 
thereafter sends a message virtual drcuit, it can 
poll the data ready flags of the service sessions 
assigned to the virtual drcuit to determine whether 
tfieir data buffers have data to transmit, and may 
remove tfte contents of various fields, indduing the 
data from the data buffers 106 whose assodated 
data ready flags as set to generate session slots 
for transfer in a virtual circuit message. 

A byte count field 110 identifies the number of 
bytes of data in the data buffer 106 and is sent with 
the data in the session slot 

A session slot type field 1 12 identifies the type 
of session slot to be sent Five types of ^ssion 
messages can be s^t induding START. STOP, 
REJECT, DATA, and STATUS messages. The con- 
tents of the session messages will be described 
below in connection with RGS. 5 and 7A through 
7D. 

Local and remote credits fields 114 and 116 in 
the session data base 100 relate to the number of 
slots that are available, with each slot relating to a 
specific amount of data. Each session slot transmit- 
ted over a virtual drcuit includes a credits field 
which identifies Ihe amount of space available in 
tiie data buffer for any response infomnation from 
the unit at the other end of the virtual circuit 
engaged in the service session. The contents of 
the credits field in the message is provided by the 
contents of the local credits field 1 14 in the session 
data base 100 of the unit transmitting tiie message. 



The contents of the remote credits field 116 is 
provided by the contents of ttie credits portion of 
the session slot received from the unit at tiie otiier 
end of the virtual circuit 

5 FIQ. 4 illustrates the various states of virtual 
circuit state machines 60 and 64 (FIG. 3A) and ttie 
various messages which can be transmitted over 
the virtual drcuit during tiiose states and which 
cause transitions among states. FIGS. 6A titrough 

10 6D detail the contents of the various virtual drcuit 
messages. As noted above, tiiree types of virtual 
circuit messages are transmitted through tiie virtual 
circuit, including a START virtual circuit message, 
a STOP virtual drcuit message, and a RUN mes- 

15 sage. The START and STOP virtual drcuit mes- 
sages are used to establish and abolish tiie virtual 
circuit and tiie RUN message is used to transfer 
information, including session slots, between ser- 
vice users and providers. 

20 With reference to FIG. 4, the state machines 60 
and 64 in tiie device server 24 and node 34 re- 
spectively are both initially in a HALTED state. 
When a user 12 requires a service provided by a 
service provider 14 connected to a rK>de 34. if no 

25 virtual drcuit exists between the device server 24 
and that node 34, tiie device server 24 transmits a 
START virtual drcuit message to node 34. 

FIG. 6A depicts the general format of a virtual 
drcuit message. With reference to RG. 6A. the 

30 message t)egins with a communications link header 
120. the format of which depends on the particular 
communiations link 16 selected for the network 10. 
In tiie spedfic embocfiment in whk^h the commu- 
nications Bnk conforms to tiie Ettiemet protocol, the 

35 communications link header includes a destination 
address field 122 and a ^urce address field 124 
which identify the particular sending and receiving 
node and device server, and a protocol type 126. 
After the communications link header 120. the 

40 message Includes a virtual drcuit header 130 
which Identifies the virtual drcuit over which the 
message is t>eing transmitted. The virtual drcuit 
header includes a destination virtual circuit iden- 
tification field 132 and a source virtual circuit iden- 

45 tification field 134 the contents of whfch are- pro- 
vided by the remote and local identification fields 
72 and 74 in data base 70 (RG. 3B). These fields 
132 and 134 identify the virtual drcuit tiirough 
which the message is being transmitted. Since 

50 each receiving unit may have several ..virtual dr- 
cutts. even between itself and tiie same node or 
device server, tiie fiekls 132 and 134 are used to 
identify the specific virtual drcuit for which the 
message received over communications link 16 is 

55 intended. If tiie message Is a START virtual circuit 
message from device server 24. with reference to 
RG. 6B, tiie destination virtual circuit identiftcation 
field 132 contains a "0", and tiie source virtual 
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circuit identification field contains an identification 
that is assigned by the device server 24. 

The virtual circuit header 130 also includes a 
message type field, an M flag and an R flag the 
contents of which are provided by fields 76, 78, 
and 80 in the virtual circuit data base 70 (RG. 3B). 
The header 30 also includes message sequence 
and acknowledgement sequence numbers taken 
fi-om counters 82 and 84. and a field 136 which 
identifies the number of session slots that may be 
included in a data field 140. The contents of ses- 
sion number field 136 is used only in connection 
with a RUN virtual circuit message (RG. 6C) de- 
scribed below. In a START virtual circuit message, 
the data field 140 contains Information used by the 
recipient in setting up the virtual circuit, and in a 
STOP virtual circuit message (RG. 6D) the data 
field contains Information as to the reason the 
virtual circuit is being stopped. 

A virtual circuit message (FIG. 6A) ends in an 
en-or check field 142 which contains a cyclic redun- 
dancy check word used to verify that the message 
was received without errors. 

With reference again to RG. 4. after the device 
server 24 transmits the START virtual circuit mes- 
sage, it shifts from a HALTED state to a START- 
ING state. Similarly, when the node 34 receives the 
START virtual drcuit message, it shifts from a 
HALTED state to a STARTING state and responds 
with either a START virtual circuit message, in- 
dicating that it will support and participate in the 
virtual circuit or a STOP virtual circuit message, 
indicating that it will not support the virtual circuit 
in either case, the node 34 retrieves the contents of 
the source virutaJ circuit identification field 134 
from the message and stores it in the remote 
identification field 72 in its virtual circuit data base 
70 as the device server's identification of the virtual 
circuit 

\A/ith reference again to RG. 6B. if the node 
responds with a START virtual circuit message, the 
node uses the contents of tfie source virtual circuit 
identification field 134 from the devk:e server's 
START virtual circuit message as the contents of 
the destination virtual circuit field 132 in its re- 
sponding START virtual circuit message. The node 
also provides the contents l^f the source virtual 
circuit IdentificatkMi field _134..(RG. 6A) as its iden- 
tification code for the virtual drcuit The devfce 
server retrieves the contents of this field, stores it 
in the remote identification field in its data base 70 
for this virtual circuit and thereafter uses it in the 
destination virtual circuit identification field 132 of 
future messages transmitted over the virtual circuit 

With reference to RG. 6D. if the node re- 
sponds with a STOP virtual circuit message, it also 
provides a source virtual circuit identification code 
and the data field 140 identifies the reason that the 



mode will not support the virtual circuit, one such 
reason may be that the node 34 is cunrently sup- 
porting other virtual circuits and has insufficient 
resources to provide support for another virtual 

5 circuit If the node 34 transmits a STOP virtual 
circuit message to the device server, tjoth the node 
and the device server return to the halted state. 
The device server may then attempt to establish a 
virtual circuit to another node connected to a ser- 

10 vice provider that provides the desired service or 
infonm the user that the service is not available if 
no other node provides the service. 

In addition, the user may determine, after the 
device server has transmitted a START virtual cir- 

15 cuit message, that it does not need to use the 
particular service. This is indicated in FIG^. 4 bjf_a. 
USER HALT directed at the STARTING state of 
device server 24. If that occurs, the device sen/er 
transmits a STOP virtual circuit message (RGS. 6A 

20 and 60) to node 34. Both virtual circuit state ma- 
chines 60 and 64 then return to the halted con- 
dition. 

If node 34 responds with a START virtual cir- 
cuit message, and if no USER HALT occurs at the 

25 device server 24 in the starting state, both the state 
machines 60 and 64 (RG. 3A) shift to a RUNNING 
state. In this condition, the device server 24 and 
node 34 can transmit RUN virtual circuit messages 
depicted in RGS. 6A and 60. In this condition, the 

30 data fiekJ 140 contains session slots which are 
descriljed below (RGS. 5 and 7A through 70). The 
number of session messages is identified in the 
session numljer field 136 In the virtual drcuit head- 
er 130 (RG. 6A). In the session messages, the 

^ device server 24 and node 34 transmit service 
infoonation between the service users 12 and ser- 
vice providers 14 (RG. 1), more specifically the 
service infonmation is transmitted between service 
state machines 66 and 68. 

40 When the user no longer needs a service, it 
disconnects ftrom the service, and, if no other users 
are using the virtual circuit a USER HALT con- 
dition exists. If the state machines 60 and 64 are 
both in the RUNNING state, the device server may 

45 transmit a STOP virtual circuit message (RGS. SA 
and 6D) to node 34 and return to the HALTED 
state. 

_ _ As. has been noted above, when the virtual 
circuit state machines 60 and 64 are in the running 

50 state, the device server 24 and node 34 can trans- 
mit RUN virtual circuit messages which include 
session slots. Using the session slots, the sesston 
state machines 66 and 68 are established, and 
service data and status information are transmitted 

55 between the service user and provider. When the 
sendee user no longer needs the service, the ses- 
sion state machines may then be abolished, there- 
by terminating the service session. The session 
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slots which are depicted in FIGS. 7A through 7D. 
By means of the session slots, the session state 
machines 66 and 68 shift among various states as 
depicted in RG. 5. 

With reference to FIG. 5, the session state 
machine 66 of device server 24 has five states, 
including a HALTED state, a STARTING state, an 
ABORT START state, a RUNNING state, and a 
STOPPING state. The session state machine 68 of 
node 34 has four states, including a HALTED state, 
a STARTING state, a RUNNING state, and a 
STOPPING state. Initially, both state machines 66 
and 68 are In a halted state, and when a user 
requests a particular service, the device server 
transmits a START session message, in a virtual 
drcuit message tiirough the virtual circuit. 

With reference to RG. 7A, tiie fonnnat of a 
session message includes a session header 150 
which Includes destination session identification 
field 152, a source session identification field 154. 
a byte count field 156. a session slot type field 
158, a credits field 160. A session data field 162 
carries information for establishing and abolishing a 
session and service session data and status in- 
fonnnation. The destination and source session 
identification fields 152 and 154 are used in tiie 
identical manner as the destination and source 
virtual circuit identification fields 122 and 124 (FIG. 
6A) described above. The contents of tfiese fields 
are stored in and taken from the remote arKi local 
Identification fields 102 and 104 in tiie session data 
base 100 (RG.3C). 

• The contents of ttie byte count field 156 iden- 
tify tiie length of tiie session data field 162, and are 
taken from tiie byte count fiekJ 110 In tiie data 
base 100. The contents of the session slot type 
field are taken from field 112 in tiie session data 
base, and identify tiie type of message being trans- 
mitted. As noted above, five types of session slots 
may be transmitted. The contents of the CREDITS 
field 1^ is taken from the k>cal credits field 114 In 
session data base 100 (RG. 30) to identify the 
number of slots ttiat are available in tiie data buffer 
106 for any response. When a unit receives a 
session slot tine contents of tiie CREDITS field 
may be stored in the remote credits field 116 of 
tiie session database 100 to indicate tiie amount of 
space in ttie data buffer 106 available for a subse- 
quent session slot transfer. 

In tiie START session slot (RG. 78) tiie ses- 
sion data field 162 provides infonnation required by 
tiie session state machine at node 34 for setting up 
the session. Such infonmation may include, for ex- 
ample, the type of sen/lce required, thereby iden- 
tifying the service provider which is to engage in 
the $en/ice session, and size of the data buffer 106 
set aside for tiie session in tiie device server. 

After ttie device server 24 transmits tiie START 



session slot, the session state machine 66 shifts to 
a STARTING state. After tiie node receives the 
START message, ttie node's session state machine 
68 shifts to tiie STARTING state and tiie node 

5 responds with either a START session slot, after 
which tfie state machine 68 shifts to ttie RUNNING 
state, or a REJECT session slot (RG. 70), after 
which tiie stale machine shifts to the HALTED 
state. In either case, tiie node 34 supplies its 

70 session identification code in the source session 
identification field 154 (RG. 7A). If ttie node re- 
sponds with a REJECT session slot, ttie credits 
field 160 also contains tiie reason that it is rejecting 
the service session. Such reasons may Include, for 

15 example, that the node is unable to provide the 
service because of inadequate resources, or that 
the node or ttie service provider is shutting down. 

With reference again to RG.5, the device serv- 
er 24 may receive the START session or REJECT 

20 session slot from node 34 when it is in ettiier the 
STARTING state or in an ABORT START state. 
The device server's session state machine 66 
shifts from ttie STARTING state to ttie ABORT 
START stage If a user disconnect request, indicat- 

25 ing ttiat the user does not want to use ttie service 
which it prevkxisly selected. Is received from a 
user before eitiier a START session or a REJECT 
sesston slot is received from node 34 . If tiie 
session state machine 66 is in the ABORT START 

30 state, and if a REJECT session slot is received, ttie 
session state machine 66 merely returns to the 
HALTEDstate. However, if a START session slot is 
received, ttie device server 24 transmits a STOP 
session slot over ttie virtual circuit to the node 

35 causing its session state machine 68 to return to 
the HALTED state. In eittier case. t>otti session 
state machines 66 and 68 return to the HALTED 
state. 

However, if the device server's session state 
40 machine 66 Is in ttie STARTING state, and if the 
device server receives a START message from the 
node 34. its session state machine shifts to the 
RUNNING state. In tiiat state, and witti ttie node's 
session state machine 68 in ttie RUNNING state. 
V 45 RUN session slots including servk:e data and sta- 
tus information may be transmitted back and forth 
between device server 24 and node 34 over the 
virtual circuit Wrtti reference to RGS. 7A and 7C, 
the session data field 162 in such messages con- 
so tains user and service provider data and status 
information. 

After the operator determines ttiat it no longer 
requires access to the service, the user requests 
disconnection from tiie service and botii state ma- 
ss chines 66 and 68 shift to ttie STOPPING state and 
then return to ttie halted state. 

RG. 8. depicts ttie timings of various mes- 
sages transmitted between a device server 24 and 
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node 34, in response to the service circuit timer 92 
and the R flag 80. the R flag in the server being set 
or cleared by the R field in a virtual circuit header 
In a message from the node. RG. 8 also illustrates 
the timings of the retransmissions of various mes- 
sages that are not r^eived by the server and 
node, in response to the re-transmit timers 90 in 
each unit. Specifically, when a node receives a 
message from the device server, it will respond 
with a message having the R field being either set 
or dear depending on whether or not the message 
Includes data. If the message does not include any 
data, the R field is clear, and the node may there- 
after transmit a second message to the device 
server which includes data. The second message 
has a set R field. This is illustrated in time (E). As 
shown at times (F) and (G). the second message 
may cross with another message from the device 
server, which may transmit a message when its 
data waiting flag is set, when its service circuit* 
timer times out The R field t)eing set forces the 
data waiting flag to be set. thereby enabling the 
server to send an acknowledging message to the 
node, whether or not it actually has data to send 
The R field being clear enables the node to there- 
after send another message with data, thereby re- 
moving the constraint on the node that it send 
messages, and therefore datzu only when it re- 
ceives messages from the server. 

A detailed description of the operation of net- 
work 10 (RG. 1) will now be presented. Periodi- 
cally, each node 34 connected into networic 10 
transmits a multicast service advertising message 
(RG. 2A) identifying the particular services which 
are available through it. All of the device servers 
receive the advertising message and establish a 
service directory (RG..2B) identifying the services 
which are available and the nodes and ratings of 
the services available through each node. The 
available services may be displayed to the oper- 
ators of the service users from the device servers' 
directories. 

When a service user 12 requires the use of a 
service, its device server 24 detenmines which 
node 34 provides the service and which has the 
highest service rating for that servtee. The device 
server 24 then detenmines whether it has a virtual 
circuit 58. between itself and that node. If no such 
virtual circuit exists, the device server transmits a 
START virtual circuit message (RGB. 6A and 6B) 
to the node to attempt to establish a virtual circuit 
over communications link 16. If the node responds 
with a START virtual circuit message, the virtual 
circuit has been e$tat>lished and the device server 
24 then establishes a session between the virtual 
circuit 58 and tf^ user 12 requesting the service. It 
will be appreciated that, if a virtual circuit already 
exists to the required node, the device server need 



not set up another virtual circuit, but instead may 
proceed to the next steps and use the existing 
virtual circuit for communications. With some com- 
munications links, such as a link conforming to the 
5 Ethernet protocol, it may be desirable to limit the 
number of users using a single virtual circuit since 
the length of each virtual circuit message is limited. 
Accordingly, even if a virtual circuit is already es- 
tablished between the device server and node, it 
10 may be desirable to establish additional virtual cir- 
cuits if too many users are already using one 
virtual circuit 

After the virtual circuit is established, the de- 
vice server 24 then may transmit virtual circuit 
75 messages through the virtual circuit including ses- 
sion messages multiplexed from several service 
sessions. A session begins with a START session 
slot (RGS. 7A and 7B) transmitted to device server 
24 to node 34 identifying the required service. In 
20 an attempt to establish a service session over the 
virtual circuit 58 with the service provider 14 which 
provides the required service. If the service session 
is established, service data and status infonmation 
can be transmitted in RUN session messages. 
25 The rate at which the device server can trans- 
mit virtual circuit messages over the communica- 
tions link 16 is limited by the server circuit timer 92 
(RG. 3B) thereby allowing messages for other vir- 
tual circuits to be multiplexed over the communrca- 
30 tions link. Furthermore, the data waiting flags 86 in 
the resfjective device swver and node inhibit them 
from transmitting virtual circuit messages through 
the virtual circuit until it has infonmation transmit. 
Thus, neither the device server nor the node trans- 
35 mits any messages over the virtual circuit 58 un- 
less information is available to be transmitted, and 
then no more often than penmitted by the server 
circuit timer. 

When a user finally determines that it no longer 
40 requires a service, the session can be abolished by 
device ^rver transmitting a STOP session slot If 
all of the sessk>ns are atx>lished for a virtual circuit 
the device server 24 may then abolish the virtual 
circuit by the transmission of a STOP virtual circuit 
45 message. 

If additional service users 12 require services 
provided by a node 34, their session stots may be 
carried by the virtual circuit messages transmitted 
over virtual drcurt 58. Thus, a single virtual circuit 
50 message transmitted over the virtual circuit 58 can 
contain messages between a number of users 12 
and service providers 14. By establishing a virtual 
circuit between the device server 24 and node 34. 
and multiplexing session slots onto a single virtual 
55 circuit message, the number of acknowledgement 
messages may be reduced to one response mes- 
sage for each virtual drcuit message. This reduc- 
tion results in. not only a reduced amount of mes- 
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sage traffic over the communications link since 
only the virtual circuit messages between nodes 
and device servers are acknowledged, and not the 
messages between particular service users and 
service providers. In the past, each message be- 
tween service users and service providers had 
been acknowledged by a separate acknowledge- 
ment message, which not only increased message 
traffic over the communications link, but also re- 
quired processing activities by the service user and 
service provider that are not required in the net- 
work 10 constmcted in accordance with the inven- 
tion. 

The foregoing description has been limited to a 
specific embodiment of the invention. It will t>e 
apparent, however, that the invention can be prac- 
ticed in networks having diverse basic construction 
than is disclosed in this specification, with the 
attainment of some or all of tiie advantage of the 
invention. Therefore, it is tiie object of ttie appen- 
ded claims to cover all such variations and modi- 
fications as come within the true spirit and scope of 
the invention. 



Claims 

1. A local area network for interconnecting ser- 
vice users and service providers, including a plural- 
ity of device server units each of which connects to 
a service user and a plurality of nodes each con- 
nected to a service provider and a communications 
link to effect communications between the nodes 
and device server units to enable said service 
users and service providers to communicate. 

A. Each node including means for transmit- 
ting a service advertising message over said com- 
munrcations link to identify the data processing 
services provided by tiie service provkiers con- 
nected thereto, and 

B. each device server unit including: 

i. advertising message receiving means 
connected to said communications link for receiv- 
ing said service advertising message; 

ii. service table means for establislijng a 
service table including a plurality of entries each 
including a node field and a service fiekl identffying 
a node arK) a data processing service provided by 
the service providers connected to the node; and 

iii. selection means responsive to an oper- 
ator requesting a service for using sakj servk:e 
table to select the node and service provider to 
provide the requested data processing service. 

2. A local area network as defined in daim 1 
wherein said service advertising message furtiier 
includes a rating for each service, said service 
table means further including means for establish- 
ing, in each entry, a rating field in response to the 



rating from the service advertising message, said 
selection means further including means for using 
tiie contents of said rating entries in said service 
table in tiie selection of the node and service 
5 provider to provide the requested service. 

3. A service provision system for connection to 
a communications link in a local area network com- 
prising: 

A. service provider means for providing a 
10 data processing service; 

6. node means connected to said service 
provider means including: 

i. service identification means for identify- 
ing a data processing service provided by said 

15 sen^ice provider means; and 

ii. service advertising message transmis- 
sion means for transmitting a service advertising 
message over said communications link to identify 
said data processing service. 

20 
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